Floppyshop 2/Floppyshop - 2.zip/Floppyshop - 2.iso/diskmags/0022-3.564/dmg-0118/153.txt

Text File | 1997-04-16 | 27KB | 647 lines

Info-Atari16 Digest         Tue, 19 Mar 91       Volume 91 : Issue 153

Today's Topics:
                          40 folder problem
                            CAD 3-D fonts
                             DSKCHR33.LZH
                       Looking for Logo for ST
                            lynx (2 msgs)
      Midi file format (Used by several midi programs). (2 msgs)
              New standards for MiNT programs? (2 msgs)
                                 oops
                     Printer redirection (again?)
             Setting Floppy Seek Rate in all TOS versions

Welcome to the Info-Atari16 Digest.  The configuration for the automatic
cross-posting to/from Usenet is getting closer, but still getting thrashed
out.  Please send notifications about broken digests or bogus messages
to [e-mail].

Please send requests for un/subscription and other administrivia to
Info-Atari16-Request, *NOT* Info-Atari16.  Requests that go to the list
instead of the moderators are likely to be lost or ignored.

If you want to unsubscribe, and you're receiving the digest indirectly
from someplace (usually a BITNET host) that redistributes it, please
contact the redistributor, not us.
----------------------------------------------------------------------

Date: 19 Mar 91 12:02:03 GMT
From:
 arizona.edu!cerritos.edu!nic.csu.net!usc!sdd.hp.com!spool.mu.edu!cs.umn.edu!uc!
 shamash!timbuk!uktriton.cray.com![e-mail] (Mike Fields)
Subject: 40 folder problem
To: [e-mail]

Does anybody know whether the famous '40 folder problem' is fixed in later
version of TOS ??

I have a 4Meg STe with a 40M FA.ST Hard drive, with about 100 folders.
Occasionally
files get corrupted, different files get into the middle of files..It
looks very much
like the problems when, with my 1040, I encountered the 40 folder
problem.

I have tried with foldr150.prg but that didn't seem to change anything,
but it could
be because the problem has already happened and until I ZERO the
partition it
will continue regardless.

Anybody any ideas ??

Thanks
Mike Fields
[e-mail]

------------------------------

Date: 18 Mar 91 07:58:48 GMT
From:
 arizona.edu!cerritos.edu!nic.csu.net!usc!rpi!uupsi!cci632!ritcsh!ultb!drp9500@a
 rizona.edu (D.R. Paradis )
Subject: CAD 3-D fonts
To: [e-mail]

  I need help!!!!!!!!

   I am using my ST and CAD-3D to generated an animation that is for a
school project.  The animation NEEDS to have animated text!

  I do not have Cyberpaint, and I cannot do this in DEGAS...it MUST be
in 3D!!

  I have scanned the ENTIRE GeNIE libraries and just about every FTP
site I can find to get ahold of a font for CAD-3D.

   If ANYONE of you have a font, or know of where I can get one PLEASE
let me know!!!!

   I tried making one and it looked like shit....



Again, this is for a school animation project and I am running out of
time....please help....



Newsgroups: rec.arts.movies
Subject: Re: A good reason to avoid Blockbuster
Summary:
Expires:
References: <[e-mail]> <[e-mail]>
Sender:
Followup-To:
Distribution:
Organization: Rochester Institute of Technology
Keywords:


  The reason that I hate them is thus....


   I work at a video store during the summer called Movies Unlimited.
They are a 5 store chain based in Philadelphia.  While I was working
there (before I started college) word got out that Blockbuster was
coming to the Philly area, but we didn't know where.  We found out.
Right across the street!
  They opened Christmas day!


[flaws begin]

   They (blockbuster) say they have over 10,000 movies.......
     reality- if they have 50 copies of BTTF3 then that is 50 movies,
etc...

   M.U.: (the store I worked at) carries aprox. 19,000 TITLES!!!
     (if we have 20 copies of a movie it counts as ONE TITLE!!)
     ( the catalog has over 23,000 TITLES!! see pg 127 of April
Premiere mag)

  The staff at BB doesn't know sh*t about movies!!!
    I asked them for movies that I KNOW were available and that M.U.
carried, they (BB) were clueless!!
    (we did spying on them to see what danger we were in....NONE!)


When BB first came in, we did see a drop in new members.  About a month
later we saw an INCREASE in new members.  BB does mass mailings to
canvas the neighbourhood.  People would come to see BB and then notice
across the street and see us and come in and join.

MU runs it like this....
     membership is $19.95
       you get...

             4 free 2 night rentals
             free catalogs (reg & adult)
             rental freebie card (stamped for each title paid for
reguardless of when returned)
             10% discount on ALL purchases (blank tapes, vids or LDs)

             a VERY movie-wise staff
             and free popcorn


in other words...........

    IT'S A REAL VIDEO STORE!!!!!



--
************************************************************************
*    Just because I'm a film major        |      < Net-address >       *
* doesn't mean I'm a Spielber-wanna-be....|                            *
*       I'm a Lynch-wanna-be!             |  [e-mail]  *

------------------------------

Date: 19 Mar 91 04:31:08 GMT
From:
 noao!ncar!elroy.jpl.nasa.gov!usc!jarthur!petunia!csuchico.edu!ekrimen@arizona.e
 du (Ed Krimen)
Subject: DSKCHR33.LZH
To: [e-mail]

Just sent DiskChart 3.3 to atari.archive.  It has a few more useful features
than version 3.0.  For example, when you click on the line of drives at
the bottom of the screen, it finds the free space on each drive.

--
         Ed Krimen  ...............................................
   |||   Video Production Major, California State University, Chico
   |||   INTERNET: [e-mail]  FREENET: al661
  / | \  SysOp, Fuji BBS: 916-894-1261        FIDONET: 1:119/4.0

------------------------------

Date: 19 Mar 91 07:58:08 GMT
From:
 arizona.edu!cerritos.edu!nic.csu.net!usc!sdd.hp.com!mips!cs.uoregon.edu!ogicse!
 milton!blake.u.washington.edu![e-mail] (Jim Black)
Subject: Looking for Logo for ST
To: [e-mail]

I'm looking for a copy of Logo for the ST (520).

Unfortunately Atari apparently doesn't ship it anymore.

Can anyone help me track down any (Atari, 3rd-party-vendor, or public domain)
logo implementations for the ST?  (Public domain with C source would be
the answer to a prayer, but any of the above would be great for now.)

Thanks for any help...
--
Jim Black  ([e-mail])

------------------------------

Date: 19 Mar 91 02:40:21 GMT
From:
 noao!ncar!elroy.jpl.nasa.gov!usc!chaph.usc.edu!aludra.usc.edu![e-mail]
 (Robert Jung)
Subject: lynx
To: [e-mail]

In article <[e-mail]> [e-mail] (Johnny Schweigl/2113674)
 writes:
>From article <[e-mail]>, by [e-mail] (Chuck
 Schul):
>> anyone know much on the atari lynx and how it is doing worldwide?
>
>Hmm. Nice thing, color, sound, could have been a success. If not Nintendo
>had thrown it's GameBoy into the market. No Color, a little less sound,
>but astonishingly small, much cheaper (that's what impresses the kids,
>i think)

  No, Nintendo hype (reenforced with NINTENDO POWER magazine) influences the
kids. As for being more competitive, you can now buy a Lynx base package
for $99 here in the 'States (versus $89 for the Gameboy).

  Portable game system market so far:

        Nintendo Gameboy        $89        B&W, 1-2 players
        Atari Lynx              $99/$149   Color, 1-8-??? players
        Sega Game Gear          $149       Color, 1-2 players
        NEC TurboExpress        $300+      Color, 1-2 players, accepts
                                             TurboGraphix-16 games

  I don't know nothin' about economics, but it looks like Atari can turn
this into a major rout and kick every other system out of the market. It
all depends on getting more games and good advertising, IMO.

                                                --R.J.
                                                B-)

//////////////////////////////////////|\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
Send whatevers to [e-mail] | If it has pixels, I'm for it.
--------------------------------------+----------------------------Lynx me up!
       "If it moves, shoot it. If it doesn't move, shoot it anyway."

------------------------------

Date: 19 Mar 91 04:34:06 GMT
From:
 noao!ncar!elroy.jpl.nasa.gov!usc!cs.utexas.edu!uwm.edu!psuvax1!psuvm!sml108@ari
 zona.edu (Scott the Great)
Subject: lynx
To: [e-mail]

In article <[e-mail]>, [e-mail] (Robert Jung) says:
>  No, Nintendo hype (reenforced with NINTENDO POWER magazine) influences the
>kids. As for being more competitive, you can now buy a Lynx base package
>for $99 here in the 'States (versus $89 for the Gameboy).
>
>  Portable game system market so far:
>
>        Nintendo Gameboy        $89        B&W, 1-2 players
>        Atari Lynx              $99/$149   Color, 1-8-??? players
>        Sega Game Gear          $149       Color, 1-2 players
>        NEC TurboExpress        $300+      Color, 1-2 players, accepts
>                                             TurboGraphix-16 games
>
>  I don't know nothin' about economics, but it looks like Atari can turn
>this into a major rout and kick every other system out of the market. It
>all depends on getting more games and good advertising, IMO.

As usual, Atari has all the good games it needs for the thing.  It's
an amazing toy, but they don't seem to care whether they sell any...
They've survived up to now on word of mouth, so why not continue
the trend?  Who needs big sales anyways?
  A pity, it would otherwise be worth developing games for it...
At least the Portfolio is doing well..
I give up on the TT for now...

Scott Le Grand

------------------------------

Date: 19 Mar 91 02:35:43 GMT
From:
 noao!ncar!elroy.jpl.nasa.gov!usc!zaphod.mps.ohio-state.edu!unix.cis.pitt.edu!pi
 tt!speedy.cs.pitt.edu![e-mail] (Bodgan Kosanovic)
Subject: Midi file format (Used by several midi programs).
To: [e-mail]

In article <[e-mail]> [e-mail] (Geert W.T. Jonkheer CCS/TS) writes:
>...
>I am writing a midi program for the atari ST. As many other programs,
>I would like to use the standard Midi file format to store
>midi data on disk. However, I don't know what the terms on this
>format are. Where can I find information about the midi file format?
>... etc.

Thank you on asking that question. I have started a year ago interesting
project (see below), not supported from any institution (as in majority of
computer music projects), which led me to the similar questions.

Problem of STANDARDS in Computer Music. MIDI standard is not enough.
Every day we can see hundreds of new "Music" products whose only purpose
is to take your money out of your pocket. Manufacturers are not thinking
of standards, they need FAST production and large profit.

I don't think that there exists a Standard MIDI File Format. It is also
important to define what kinds of information you would like to see
in such file (multitrack recording of MIDI events, MIDI dump of patch
parameters, music scores of composition, live performance protocol file,
etc., etc.)

As far as I know MIDI Sample Dump Standard is THE only standard which can
be related to 'files' (although it doesn't imply usage of files). It is
more like MIDI Sample Dump Packet Protocol Description.

If you thought of MIDI events recording, and file containing such
informations, I'm afraid that widely accpeted standard DOES NOT exist.

>The information i would like to get is:
>
>1) Are the parameters in the standard midi file machine independant.
>   Can all parameters be used on every midi instrument?
>
    They should be ! Particular music device drivers should hide all
    characteristics of particular instrument. (Layered approach).
    Some MIDI instruments, however, are less powerful, so one cannot
    expect of all instruments to respond to all possible events.
    (Such events should be skipped or mapped into others when possible).

>2) How are the parameters orded in the midi file.
>
    Again, I am not sure what 'parameters' are you talking about ?
    If you think of MIDI composer/recorder, some hierarchy in file
    definition should be higly welcomed, as well as modularity, in
    order to minimize duplicate information (repetition of events or
    bars or groups of bars).

    If you think of patch dump files. Ordering doesn't matter.

>3) Can machine dependant data (for example midi exclusive data) also be
>   stored in the midi file, or must i use my own format to store these
>   data.
>
    This was a project I've mentioned above. I've started writing a
    tool which could provide MIDI programmers with a possibility of
    producing MIDI applications capable of controlling ANY type of
    MIDI device by using Object Oriented definition of Exclusive Data.

    To simplify, my Universal Device Driver Code Generator should produce
    driver code in plain C language if given simple ASCII file containing
    definition of any MIDI instrument. Once you have your application
    working with one relatively complex instrument you can be positive
    that it should work WITHOUT change with ANY other instrument.
    The only thing you should do after purchasing NEW instrument would
    be to enter your favorite editor and type in the definition of
    your NEW instrument's system exclusives using META language designed
    for such operations.

    Actual application would use STANDARD library calls like in GKS,
    GEM or similar graphic standard libraries (open_virtual_workstation,
    send (handle, data), receive(handle, data), ... where handle is
    music device ID opened at the beginning of application (or later)).

    The answer on your question is YES, but again I am not sure that
    there exists a standard (world wide). Unfortunately, I didn't
    complete my project, because nobody wanted to pay me, and on the
    other side people who are paying me expect from me to do other
    things. (I completed parser for META language, and started
    code generation, I also defined "standard" formats, all known
    exclusive messages should fit in, and I also started to think of
    mechanism which could provide you to include in definition file
    even new system exclusive message formats which are likely to
    appear in the future).

    I would like one day to see this or similar system working and
    to see happy faces of all music people after purchasing new
    instrument and configuring it after just a couple of minutes.

    Why should we purchase new device drivers from the manufacturers
    when we could define new one in 10 minutes !!!

>4) Many midi music programs are using the standard control commands
>   for manipulating the music (such as bender, hold etc.)
>   I have not seen a program use control commands that are
>   particularly for a midi instrument (such as sound effectors which
>   are not descriped in the midi standard).
>   Programs must use the standard control commands and the
>   'user defined' control commands for manipulating music
>   (i think) to get the most flexibility.
>   Is there a program on the market that uses this concept?
>
    I hope one day we shall be able to purchase Real-Time Music
    Workstation capable of Music/Sound/Image processing. I hope
    it will cost less than 2000$ US dollars and will fit size of
    my desk. Some simple sound processing control can be implemented
    and IS implemented on some Digital Sound Processors. It is often
    just simple preset/effect change which is useless in 99% percent
    of real life situations. What I would like to see (as well as you)
    is real time change in reverberation or delay characteristics
    possibly controlled from the external source (joystick or similar
    controller). In a year or two Digital Signal Processing technology
    will be capable (I hope) of doing such things in real time and for
    less than 2000$ dollars.

    The problem is when the manufacturers are going to lower their
    extremely high prices. (Why some manufacturers of sampling keyboards
    are selling hard disk drives (40MB, extremely slow) for 900$ (!!!)
    when such drive can be purchased for as low as 200-300$ ?)

    I would also like to easily control tempo changes, dynamics,
    timbral characteristics (all in real-time and possibly from the
    external sources). AND I WOULD LIKE TO SEE A SOFTWARE PRODUCT WITH
    ALL THESE CAPABILITIES WHICH I CAN UNDERSTAND IN ONE DAY, WITHOUT
    PAIN of READING 100s of MANUAL PAGES WRITTEN WITH THE ONLY PURPOSE
    OF justifying WRONG DECISSIONS THEY MADE DURING DESIGN & IMPLEMENTA-
    TION.

    That would be all for know. Please forgive me on length of a text.

Bogdan R. Kosanovic
4705 Fifth Ave, Apt 1-L
Pittsburgh, PA 15213
U.S.A.
(412)-681-2019

E-Mail: [e-mail]     (please use this address)

------------------------------

Date: 19 Mar 91 04:44:17 GMT
From: stanford.edu!neon.Stanford.EDU![e-mail] (Ismail Dalgic)
Subject: Midi file format (Used by several midi programs).
To: [e-mail]

In article <[e-mail]> [e-mail] (Bogdan Kosanovic) writes:
>In article <[e-mail]> [e-mail] (Geert W.T. Jonkheer CCS/TS)
 writes:
>>...
>>I am writing a midi program for the atari ST. As many other programs,
>>I would like to use the standard Midi file format to store
>>midi data on disk. However, I don't know what the terms on this
>>format are. Where can I find information about the midi file format?
>>... etc.
>
>Thank you on asking that question. I have started a year ago interesting
>project (see below), not supported from any institution (as in majority of
>computer music projects), which led me to the similar questions.
>
>Problem of STANDARDS in Computer Music. MIDI standard is not enough.
>Every day we can see hundreds of new "Music" products whose only purpose
>is to take your money out of your pocket. Manufacturers are not thinking
>of standards, they need FAST production and large profit.
>
>I don't think that there exists a Standard MIDI File Format. It is also
>important to define what kinds of information you would like to see
>in such file (multitrack recording of MIDI events, MIDI dump of patch
>parameters, music scores of composition, live performance protocol file,
>etc., etc.)
>
>As far as I know MIDI Sample Dump Standard is THE only standard which can
>be related to 'files' (although it doesn't imply usage of files). It is
>more like MIDI Sample Dump Packet Protocol Description.
>
>If you thought of MIDI events recording, and file containing such
>informations, I'm afraid that widely accpeted standard DOES NOT exist.


I'm afraid that what you are saying is wrong.  A MIDI file format for
storing the MIDI event sequences DOES exist, and it is currently being
used by many commercial programs.  You can get its specs via anonymous
ftp from ucsd.edu.  Unfortunately the specs there are pre - version
1.0 (i.e., before it was approved by the MIDI Manufacturers'
Association), but I don't think there is a big difference.  Also,
check your favorite MIDI BBS for utilities to convert between
the MFF files and several other commercial sequence formats such as
Cakewalk files.

--Ismail Dalgic
[e-mail]

------------------------------

Date: 19 Mar 91 20:03:19 GMT
From:
 noao!ncar!elroy.jpl.nasa.gov!sdd.hp.com!spool.mu.edu!munnari.oz.au!brolga!bunyi
 p.cc.uq.oz.au!qut.edu.au![e-mail]
Subject: New standards for MiNT programs?
To: [e-mail]

In article <[e-mail]>, [e-mail] (David
 Megginson) writes:
>
> It's time for us to start designing programs and libraries which will
> run under future versions of MiNT which support bigger and better
> file systems. A good idea might be to include some dummy system calls
> which MiNT-aware programs can use to replace Fsfirst(), Fsnext() etc.
> The new system calls should work the same for now, but require a much
> larger buffer for the program name. That way, in the future when MiNT
> supports better file systems, MiNT programs will not have to be recompiled
> to be able to support names like Nethack.Source.tar.Z. If we just put
> all of the calls in place now, our work will be easier in a year or two.
>
> Comments? Perhaps we should write a spec sheet for what programs/libraries
> should do to be upwards compatible with future MiNT versions. This is
> something that we can do together on the net, and all Eric would have
> to do is approve it and include it in the distribution.
>
Huh, why not use dirent ??? This seems reasonably capable and is portable
to boot ???



>
> --
> ////////////////////////////////////////////////////////////////////////
> /  David Megginson                      [e-mail]          /
> /  Centre for Medieval Studies          [e-mail]     /
> ////////////////////////////////////////////////////////////////////////

------------------------------

Date: 19 Mar 91 10:51:39 GMT
From: noao!asuvax!ncar!elroy.jpl.nasa.gov!jato!hanauma![e-mail] (Howard
 Chu)
Subject: New standards for MiNT programs?
To: [e-mail]

In article <[e-mail]> [e-mail] writes:
>Huh, why not use dirent ??? This seems reasonably capable and is portable
>to boot ???

I'd agree, we should try to hide the Fsfirst/Fsnext layer completely and
use the Unix *dir routines instead. (This seems reasonable, given MiNT's
apparent intent to provide as much BSD functionality as possible...)
--
  -- Howard Chu @ Jet Propulsion Laboratory, Pasadena, CA
        Disclaimer: How would I know, I just got here!

------------------------------

Date: 18 Mar 91 08:17:58 GMT
From:
 arizona.edu!cerritos.edu!nic.csu.net!usc!rpi!uupsi!cci632!ritcsh!ultb!drp9500@a
 rizona.edu (D.R. Paradis )
Subject: oops
To: [e-mail]

  oops...please ignore the part about Blockbuster Video.

I didn't realize that the article was not posted and got appended to
my dead.article file.


I still need help with the CAD 3-D fonts though....

--
************************************************************************
*    Just because I'm a film major        |      < Net-address >       *
* doesn't mean I'm a Spielber-wanna-be....|                            *
*       I'm a Lynch-wanna-be!             |  [e-mail]  *

------------------------------

Date: 19 Mar 91 07:51:56 GMT
From: mcsun!hp4nl!rivm!rivm39![e-mail] (Fokke de Boer)
Subject: Printer redirection (again?)
To: [e-mail]

Hello netlanders,

Some time ago there was a thread on ** PRINTER REDIRECTION ** on c.s.a.st.
I didn't follow it back then, because I had no need for redirection.

But as always, nothing changes as much as the human mind :-) so now
I **AM** interested.
Sofar I have tried the program BARREL from atari.archive, but it doesn't
fill my needs. I have some programs capable of printing, but since I don't
have a fine printer I want to use the printer at work, but I don't want
to bring my ST every time.
These programs don't react to BARREL being resident: the print option is
still disabled. And printing from WordPerfect running under DOS (PC-Speed)
reports the printer being not ready.
So, what I need is a program that makes the Atari think a printer is
connected, although there isn't. Printer output should be redirected to
a file (and not to a buffer that has to be transferred manually to file).
Ideally, this program runs from the AUTO folder, and thereafter I "have
a software-printer" .

Any input appreciated, preferably by e-mail!

Fokke de Boer ([e-mail])

------------------------------

Date: 19 Mar 91 04:44:54 GMT
From: noao!ncar!elroy.jpl.nasa.gov!jato![e-mail] (Van Snyder)
Subject: Setting Floppy Seek Rate in all TOS versions
To: [e-mail]

Here's the poop on setting the seek step rate for floppies, from page 60
of the Rainbow TOS distribution:

"Floprate:      -  Floprate, XBIOS function 41, checks or sets the seek
                   rate for a floppy drive.  This is new; the seek rate
                   must be set with (previously) undocumented variables
                   on earlier versions of TOS.

                   Floprate example.

        int devno, newrate;
        oldrate = Floprate(devno,newrate);

                   This returns the current seek rate if newrate is -1,
                   otherwise sets the seek rate to newrate.  For doing this
                   with previous versions of TOS, the seekrate byte
                   locations for drive A and B are:

                   OS Version   Drive A   Drive B
                   ----------   -------   -------
                    0x0100       $A09      $A0D
                    0x0102       $A4F      $A53

                   In either case valid seek rate byte values are:

                   Value        Rate
                   -----        ----
                   00           6 ms
                   01          12 ms
                   02           2 ms
                   03           3 ms

                   This call does not range check the drive ID or new seek
                   rate.  If devno is zero, it assumes drive A:, if
                   nonzero, drive B:."  That's 41 decimal.
You can get the TOS version from offset 02.w from the place pointed at
by 0x4F2.L (_sysbase).

--
[e-mail]
ames!elroy!jato!vsnyder
[e-mail]

------------------------------

End of Info-Atari16 Digest
******************************